Every presentation a command declares is required - #171

…answers to

Spec R7 requires product-repo e2e in prisma/prisma and composer, and
says nothing about the grammar this binary ships.

The binary answers to 89 commands, counted by walking --help from the
root through every group. 40 have an e2e test. 49 do not.

26 of the 49 come from other packages — 22 from orm-toolchain, 4 from
composer — and none of them is run by this repo's e2e suite at all,
though it is this binary that breaks when a mount breaks. #171 found
that the hard way: requiring next at runtime made migration list exit 2,
caught only by an in-process mount test.

The other 23 are this repo's own, listed with what each needs.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Signed-off-by: willbot <w.a.madden+machine@gmail.com>
Signed-off-by: Will Madden <madden@prisma.io>

…e engine fill them in (prisma#30004)

Here is the entire change, repeated across 21 files:

```diff
  // src/orm/migration/list.ts
  function listPresentations(inputs: { … }): Presentations {
    return {
      human: (): readonly Block[] => [
        { kind: 'fields', rail: true, rows: [ … ] },
        { kind: 'drawing', lines: toneDrawing(inputs.tree) },
      ],
+     stdout: () => [],
+     next: () => [],
      json: () => inputs.list,
    };
  }
```

## What those four things are

Every CLI command hands the engine four ways of reporting what it did,
and the engine uses the ones the run needs:

| | what it is | who reads it |
| --- | --- | --- |
| `human` | the blocks a person sees, on stderr | someone at a terminal
|
| `stdout` | plain data lines, on stdout | a pipe, a script |
| `json` | the `result` inside the `--json` envelope | a program parsing
output |
| `next` | suggested follow-up commands | the person, after the command
finishes |

Today `human` is required and the other three are optional. When a
command leaves one out, the engine substitutes a default — an empty list
for `stdout` and `next`.

## The decision

**The engine is dropping those defaults and requiring all four.** A
command will state what it publishes on each channel rather than
inheriting it by omission.

This PR does that stating for the ORM commands. Nothing else changes.

## Why it matters, concretely

Once the engine stops substituting, it calls whatever the command
declared. Our commands declare two of the four, so it calls functions
that are not there:

```
$ prisma migration list
# exit 2
```

That is `stdout` in human mode — the default for anyone at a terminal —
and `next` in both modes. It affects the 21 command files in this diff.

Worth noting how it was found, because it says something about our
coverage: **this package's own suite passes either way.** It never sees
the engine version it will be mounted against. The failure only appears
when you run the assembled `prisma` binary, which neither repo tests
today.

## Behaviour is identical

Every added `stdout` and `next` returns the same empty array the engine
was already substituting. This is a no-op at runtime, on purpose.

What it buys is visibility. `stdout` is the channel a script reads, and
today every ORM command returns nothing on it — not as a decision, but
because nobody wrote one. After this, that gap is a visible `() => []`
in each file, and a command that ought to emit machine-readable lines
can be given them one at a time, deliberately and reviewably.

## Timing: this does not wait on anything

The three fields are optional in the engine we pin (`0.0.9`) and in the
newest published engine (`8.0.0-rc.1`, on the `next` tag) alike. The
version that requires them is not published yet — it is
[prisma-cli#171](prisma/prisma-cli#171), still
open. So this can merge and ship now, and the engine can then require
the fields without breaking us.

## How I know nothing was missed

I made the four fields required in the installed engine's type
declarations and typechecked the package against that — the exact
condition the new engine imposes. Zero errors across `src/` afterwards,
and it caught one site a grep had missed: a fixture in
`test/orm/define-command.test.ts`. The declarations were then restored,
so nothing in this diff touches `node_modules`.

`pnpm build`, `typecheck` and `lint` clean; **155 test files, 1943 tests
passing.**

## Alternatives considered

**Handle it in prisma-cli instead, by calling the missing channels
defensively.** That shim exists today and works. Rejected as the
permanent answer: it stands in for a declaration we can simply write in
our own code, and it keeps the engine guessing on behalf of every ORM
command we add from here.

**Wait for the strict engine to publish and do this together with the
version bump.** Rejected: the fields are optional in every published
engine, so this ships now. Waiting only keeps the consumer shimmed for
longer and couples two releases that need not be coupled.

**Bump the engine pin from `0.0.9` to `8.0.0-rc.1` in the same PR.**
Worth doing — an install of `@prisma/cli` currently carries two copies
of the engine because this package pins `0.0.9` while prisma-cli builds
`8.0.0-rc.1` — but it is a large version jump with its own surface
changes, and it is not needed to make the presentations correct. Kept
separate so this diff stays a reviewable no-op.

**Give the commands real `stdout` output now rather than `() => []`.**
Rejected for this PR. What `migration list` should print to a pipe is a
genuine per-command design question and a behaviour change deserving its
own review. `() => []` is exactly what ships today, which keeps this
diff a no-op reviewable in one pass.

Signed-off-by: willbot <w.a.madden+machine@gmail.com>
Signed-off-by: Will Madden <madden@prisma.io>
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>